fix: diagnose unified connection services - #9680

Previously missed (2) — in code that hasn't changed since the last review.

cli/azd/extensions/azure.ai.agents/internal/cmd/nextstep/connections.go:60

• This always adds bundled connections after split services, but the provisioning path does not use the same merge rule: collectConnections returns as soon as any azure.ai.connection service is present (internal/cmd/resource_services.go:538-540) and ignores all bundled entries. In a partially migrated project, Doctor can report a unique bundled connection as missing and recommend azd provision, although provisioning cannot create it. Align diagnostics with the existing all-or-nothing fallback, or update provisioning to implement the same per-name precedence.

	collectBundledConnections(
		ctx,
		src,
		envName,
		projectCfg,

cli/azd/extensions/azure.ai.agents/internal/cmd/nextstep/evaluate.go:73

• azd treats an explicitly empty condition as absent/enabled (pkg/project/service_config.go:124-125, and internal/project/service_target_agent.go:450-452 does the same), but this branch returns false for condition: "". Doctor can therefore omit a connection that provisioning considers active and incorrectly skip remote.connections. Preserve empty-string-as-enabled while keeping non-empty whitespace-only values false, and update the new test that currently groups both cases together.

	if strings.TrimSpace(value) == "" {
		return false, nil

cli/azd/extensions/azure.ai.agents/internal/cmd/nextstep/connections.go:377

• Requiring kind drops a supported bundled-configuration shape. collectConnections used by provisioning accepts a ServiceTargetAgentConfig containing connections without an inline agent definition (resource_services_test.go:353-378), but this branch skips that same map and Doctor reports no configured connections or falls back to the manifest. Detect bundled connection config independently of whether the service also carries an inline agent definition, and cover the no-kind legacy config case here.

		if !mapHasKind(resolved) {
			continue
		}

Previously missed (1) — in code that hasn't changed since the last review.

cli/azd/extensions/azure.ai.agents/internal/cmd/nextstep/condition.go:73

• [azd-code-reviewer] When an azd environment is selected, this lookup treats an unset azd value as empty instead of falling back to the process environment. Core provisioning evaluates conditions with environment.Environment.Getenv, which falls back to os.Getenv (pkg/environment/environment.go:188-198), so ${DEPLOY_CONN} can enable and provision a connection while Doctor skips it. Preserve that fallback here so diagnostics use the same enabled-service set as provisioning.

		value, err := src.EnvValue(ctx, envName, name)

Previously missed (1) — in code that hasn't changed since the last review.

cli/azd/extensions/azure.ai.agents/internal/cmd/doctor/checks_connections.go:138

• azd-code-reviewer: ConnectionLoadErrors is never populated from agent.manifest.yaml; manifest read and parse failures are intentionally ignored in connections.go:305-312. Directing users to fix that file points at an unrelated source and conflicts with the PR’s stated out-of-scope malformed-legacy handling. Limit this suggestion to azure.yaml and its $ref files.

					Suggestion: "Fix azure.yaml, its $ref files, or the " +
						"legacy agent.manifest.yaml, then retry " +
						"`azd ai agent doctor`.",